Publishing and deploying business processes

ABSTRACT

Publishing a business process includes accessing a business process that includes activities, where each activity is associated with an abstract role. Organizational roles are accessed. Each abstract role is matched with an organizational role. The business process is published to a data repository by creating a plurality of object classes representing the business process having the matched organizational roles.

RELATED APPLICATIONS

This application claims benefit under 35 U.S.C. § 119(e) of U.S.Provisional Application Ser. No. 60/280,622, filed Mar. 30, 2001,entitled “METHOD AND SYSTEM FOR AUTOMATING BUSINESS PROCESSES.”

This application is related to U.S. patent application Ser. No.09/___,___, entitled “DESIGNING BUSINESS PROCESSES USING PARAMETRICROLES,” Attorney's Docket 067833.0130, filed concurrently with thepresent application.

This application is related to U.S. patent application Ser. No.09/___,___, entitled “DESIGNING BUSINESS PROCESSES USING DISTRIBUTEDPROCESS FLOWS,” Attorney's Docket 067833.0131, filed concurrently withthe present application.

This application is related to U.S. patent application Ser. No.09/___,___, entitled “EXECUTING BUSINESS PROCESSES USING PERSISTENTVARIABLES,” Attorney's Docket 067833.0135, filed concurrently with thepresent application.

TECHNICAL FIELD OF THE INVENTION

This invention relates generally to the field of business processautomation and more specifically to publishing and deploying businessprocesses.

BACKGROUND OF THE INVENTION

Organizations typically automate their business processes to managetheir operations. A business process includes a series of activitiesthat are undertaken to perform the operations of an organization. Forexample, a business process may describe activities for processing asales order, such as the steps of receiving a sales order, checking thepayment history, checking the inventory, and so on. An organization mayautomate a business process by having a computer perform some activitiessuch as receiving a sales order. A business process may also beautomated by having a computer remind human participants of activitiesthat need to be performed. For example, a computer may send an emailmessage notifying an account manager to check the payment history of aclient.

Automating business processes, however, has posed challenges. Designingautomated business processes involves the use of software programs,which business process designers may find difficult to use. Moreover,testing automated business processes requires performing trial runs of abusiness process, which may be difficult to do without disrupting theactual users of the business process. Consequently, automating businessprocesses has posed challenges.

SUMMARY OF THE INVENTION

In accordance with the present invention, disadvantages and problemsassociated with previous techniques for business process design may bereduced or eliminated.

According to one embodiment of the present invention, publishing abusiness process includes accessing a business process that includesactivities, where each activity is associated with an abstract role.Organizational roles are accessed. Each abstract role is matched with anorganizational role. The business process is published to a datarepository by creating a plurality of object classes representing thebusiness process having the matched organizational roles.

Certain embodiments of the invention may provide numerous technicaladvantages. A technical advantage of one embodiment is that businessprocesses may include activities with compensation tasks. Compensationtasks are executed when a task of an activity fails to execute, thusallowing for the performance of the activity to continue uninterruptedto completion. Compensation tasks may be used for automated businessprocesses to maintain business process consistency.

Another technical advantage of one embodiment is that an activity may beassociated with an abstract role in order to specify users representingpeople responsible for performing the activity. The association mayprovide for abstract business process modeling, which may allow for thecreation of business process templates creation that may be used fordifferent organizations.

Another technical advantage of one embodiment is that the processes ofpublishing and deploying business processes are separated. By separatingthe publication and deployment processes, a business process may bepublished and tested, without deploying the business process to users.Another technical advantage of one embodiment is that persistentvariables are used. Persistent variables allow a value related to aninstance of a business process to be efficiently carried from oneactivity of the business process to another activity of the samebusiness process or of another business process.

Certain embodiments of the invention may include none, some, or all ofthe above technical advantages. One or more other technical advantagesmay be readily apparent to one skilled in the art from the figures,descriptions, and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and forfurther features and advantages, reference is now made to the followingdescription, taken in conjunction with the accompanying drawings, inwhich:

FIG. 1A is a block diagram of one embodiment of a system for automatinga business process in accordance with the present invention;

FIG. 1B is a block diagram of one embodiment of a data repository thatmay be used with the system of FIG. 1A;

FIG. 2 illustrates one embodiment of designer screen that may be usedfor automating business process modeling;

FIG. 3 illustrates one embodiment of task table that may be used forrecording tasks and compensation tasks for a business process activity;

FIG. 4 illustrates one embodiment of an activity properties screen thatmay be used to define tasks and compensation tasks;

FIG. 5 is a flowchart illustrating one embodiment of a method fordefining, implementing, and executing tasks and compensation tasks;

FIG. 6 illustrates one embodiment of an organizational roles screen thatmay be used to configure organizational roles that can have values;

FIG. 7 illustrates one embodiment of assign organizational roles screenthat may be used to assign organizational roles to users;

FIG. 8 illustrates one embodiment of a match roles screen that may beused to match abstract roles with organizational roles when an abstractbusiness process model is published to an organization;

FIG. 9 is a flowchart illustrating one embodiment of a method fordefining and implementing organizational roles;

FIG. 10 illustrates one embodiment of a publish screen that may be usedto publish and deploy a business process;

FIG. 11 is a flowchart illustrating one embodiment of a method forpublishing a business process;

FIG. 12 is a flowchart illustrating one embodiment a method forimplementing an instance variable at runtime or execution time;

FIG. 13 is a flowchart illustrating one embodiment a method forimplementing an argument variable when communicating to businessprocesses;

FIGS. 14 through 18 illustrate distributed process flow; and

FIG. 19 illustrates polymorphic sub-processes.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram of one embodiment of a system 100 forautomating a business process. A business process includes a series ofactivities that are undertaken to perform the operations of anorganization. For example, a business process may describe activitiesfor processing a sales order, such as the steps of receiving a salesorder, checking the payment history, checking the inventory, and so on.System 100 allows an organization to automate business processes.

Referring to FIG. 1A, a user group 110 may access system 100 through acommunication network 114. An organization may use system 100 toimplement business processes to solve problems. User group 110 comprisesa data set of user identifiers, which may represent, for example, peoplewho may access system 100 using computing modules such as personalcomputers. For example, user group 110 may include a designer 122, whichrepresents a person who uses system 100 to design a business processmodel.

User group 110 also includes users 124, which represent people who maybe responsible for performing activities of a business process. Forexample, a user 124 may be responsible for receiving a sales order andverifying its completeness. System 100 allows designer 122 to design abusiness process model. In turn, system 100 notifies users 124 of theactivities that need to be performed.

Users 124 may be logically organized into user sets 123, where users 124of a user set 123 represent people who are responsible for the executionof specific activities. The logical grouping of users may be defined andstored in system 100. A user 124 may be a member of any suitable numberof user sets 123. For example, user 124 c is a member of user sets 123 aand 123 b. User sets 125 may be associated with, for example,organizational roles defined within an organization, such as asalesperson role.

Communication network 114 may include wired telecommunications,satellite, microwave, or other suitable wired or wireless networks, or acombination of the preceding.

System 100 includes an interface module 116, modules 112, and a datarepository 118. Interface module 116 may include a website 126, aninterface 128 deployed in website 126, and a security module 129.Website 126 allows for communication of information between user group110 and system 100. Interface 128 may comprise a hypertext markuplanguage (HTML) interface that receives instructions through a webserver deployed in website 126 in order to perform operations includedin instructions from users 124. Security module 129 may provide, forexample, password security, resource access security, and/or systemsecurity. Security module 129 may be used for authentication proceduresand may be adapted to the security policy and infrastructure of anorganization.

System 100 provides advantages in automating business processes. System100 generates business processes that include compensation tasks. Acompensation task is executed when an associated task of a businessprocess activity fails to execute, allowing the business process toachieve a steady and consistent state before its execution is retried.The business process instance may proceed to the next business processactivity. Additionally, system 100 allows for specification of peoplewho are responsible for performing the activities of a business processthrough user sets 123 defined in system 100, thus allowing anorganization to readily automate the business process.

Moreover, system 100 separates the processes of publishing and deployingbusiness processes. By separating the publication and deploymentprocesses, a business process may be published and tested, without beingdeployed to users 124 of the production environment. Furthermore, system100 provides persistent variables, which allow a value to be transferredfrom one activity to another activity of the same business process or ofa different business process using process arguments.

Modules 112 include a catalog manager 130, a process designer 132, anorganizational settings module 134, an execution console 136, andexecution engines 140 coupled as shown in FIG. 1A. In general, catalogmanager 130 may be used to define and specify the components or programsthat can be called from a business process. Process designer 132 may beused to model business processes to be deployed in an organization.Organizational settings module 134 may be used as a front-end module todefine business process participants and how they are going to beorganized.

Execution console 136 may be used to manage the execution engine inwhich business processes are deployed, and may be accessed by users 124of user group 110. Execution engines 140 may be used to deploy businessprocesses, execute tasks requested by users 124, and perform automatedbusiness process activities. Modules 112 may store and retrieve datausing a data repository 118 that includes an organizational datarepository 150 and a transactional database 170.

According to one embodiment, catalog manager 130 defines, describes, andorganizes components. A component may comprise a modular softwareroutine that has been compiled, and may be used with other components orprograms. Catalog manager 130 stores components in data repository 118and supplies components to process designer 132 and execution engines140.

Process designer 132 is used to design business processes, which arestored in data repository 118 once the business processes are published.While the business process is being designed using Process Designer 132,the business process model definition may be stored in a local computer.Business processes are described in more detail in connection with FIG.2. Process designer 132 may also be used to publish business processesto data repository 118 as well as to deploy business processes toexecution engine 140.

According to one embodiment, business processes are designed on acomputer by manipulating graphical icons on a computer screen. Anexample of a computer screen that may be used to design a businessprocess is described in connection with FIG. 2.

FIG. 2 illustrates one embodiment of a designer screen 200 forautomating a business process 210 on a computer. Business process 210includes a sequence of activities 212 coupled by transitions 214. Forexample, business process 210 may include a sequence of activities 212for processing a sales order. Each activity 212 comprises a series oftasks that are executed to complete activity 212. For example, anactivity 212 that notifies a client of an incomplete sales order mayinclude the task of “sending an email message to the client.” Tasks mayexecute components catalogued using catalog manager 130 and madeavailable through publishing and deployment.

To design business process 210, activities 212 are placed in a designerwindow 202. Activities 212 may have a specific semantic, which may bedesignated by a particular color or shape. Custom colors and shapes maybe used in response to user preference. For example, activity 212 a maybe an activity that is used to begin a business process, and may bedesignated by a triangular shape pointing in the right-hand direction.Activity 212 f may be an activity that is used to end a businessprocess, and may be designated by a triangular shape pointing in theleft-hand direction.

Transitions 214 are used to indicate a next activity that is to beinitiated after executing a previous activity. For example, transition214 a indicates that activity 212 b is to be initiated after theexecution of activity 212 a. Transitions 214 may indicate multiple nextactivities that are to be initiated after the execution of a previousactivity. For example, transitions 214 b and 214 c indicate thatactivities 212 c and 212 d, respectively, are to be initiated after theexecution of activity 212 b.

Depending upon how business process 210 is defined, either one or bothactivities 212 c and 212 d may be initiated after activity 212 b. Forexample, business process 210 may be defined such that depending upon adecision made at activity 212 b, either activity 212 c or activity 212 dis initiated after the execution of activity 212 b. Additionally,transitions 214 may direct multiple activities to a single nextactivity. For example, transitions 214 d and 214 e direct activities 212c and 212 d, respectively, to activity 212 e.

Business process 210 also includes abstract roles 216 that are used atdesign time to represent in the abstract user sets 123 that representpeople of an organization who are responsible for performing an activity212. Abstract role 216 may be matched to an organizational role. Anabstract role represents in the abstract a set of users responsible forperforming the activity, and the organizational role may take on valuesthat correspond to actual users 124 of an organization. For example, anabstract role represents a salesperson in the abstract, and theorganizational role describes actual salespeople of an organization. Atdesign time, abstract roles are used instead of organizational roles,such that a single business process may be used for multipleorganizations, incorporating the concept of template models.

An organizational role may be parametric, that is, the organizationalrole may be assigned a value that corresponds to user set 123, and maytake on multiple values that correspond to different user sets 123.Users 124 of user set 123 represent people responsible for performingactivity 212. For example, users 124 of one user set 123 may representsalespeople from one state, and users of another user set 123 mayrepresent salespeople from another state. An organizational role may beused to create groups of users that can be instantiated with, forexample, salespeople from different states. An advantage of definingparametric roles is that the assignment of a user set 123 may bedetermined dynamically based on business process rules.

Abstract roles 216 are specified for activities 212 by placingactivities 212 in the appropriate abstract role column. For example,abstract role 216 a is specified for activity 212 a, and abstract role216 b is specified for activities 212 b and 212 e. To summarize,business process 210 may include activities 212 coupled by transitions214 and associated with abstract roles that may be associated with realorganizational roles stored in data repository 118.

Referring back to FIG. 1A, organizational settings module 134 definesthe settings for an organization. Organizational settings may describeuser sets 123, organizational roles and associated values if theorganizational roles are parametric, and organizational units of theorganization.

Execution engines 140 manage the execution of instances of businessprocesses 210. An example of an instance of a business process may beprocessing a specific sales order using a business process forprocessing sales orders. Execution engine 140 is used to execute aninstance of business process 210 that has been deployed on it. Executionengine 140 retrieves and collects business process 210 definitions fromorganizational data repository 150. Execution engine 140 manages theexecution of a particular task of a specific business process instancerequested by a user 124 if the activity is interactive. Execution engine140 automatically executes the task if the activity is an automated one.

The state of the instance is maintained in transactional database 170 ifthe task is completed successfully. Each execution engine 140 may beassociated with its own transactional database 170 that may comprise,for example, a relational database management system (RDBMS). “Each” asused in this document means either each member of a set or each memberof a subset of a set.

Execution console 136 defines and manages execution engines 140. Forexample, execution console 136 defines port settings for executionengines 140 and database settings for transactional databases 170associated with execution engines 140.

FIG. 1B is a block diagram of one embodiment of data repository 118 ofsystem 100 of FIG. 1A. Data repository includes organizational datarepository 150 and transactional database 170. Organizational datarepository 150 includes information that is typically maintained throughmultiple executions of instances of business processes, and may bereceived from organizational settings 134 and execution console 136.Organizational data repository 150 may comprise, for example, alightweight directory access protocol (LDAP) database.

Organizational data repository 150 includes business process definitions152 and organizational data 154. Business process definitions 152include activities, transitions between the activities, and abstractroles associated with the activities. Business process definitions 152may include a task table 159 that records the tasks of an activity andtheir associated compensation tasks. A compensation task is executedwhen its associated task fails to execute. The compensation task undoesthings done by the associated task to a particular business processactivity, resulting in a consistent state in case a task fails. Tasktable 159 is described in more detail in connection with FIG. 3.

Organizational data 154 includes information about the organization.Organizational roles 160 include information about organizational rolesand associated users 124. Organizational roles 160 are matched withabstract roles 216 in order to specify users 124 representing people whoare responsible for performing the activities of business processesdefinitions 152. Matchings 164 record the association between abstractroles and corresponding organizational roles when publishing aparticular business process using system 100.

Transactional database 170 includes persistent variables that recordinformation that is typically maintained for an instance of a businessprocess. For example, a value describing the requested quantity of goodsfor a specific sales order is typically maintained for the instance thatprocesses the specific sales order. The value is generally not neededfor instances that process other sales orders.

Persistent variables include instance variables 172 and argumentvariables 174. Instance variables 172 record values that may be passedfrom one activity of a business process to another activity of the samebusiness process. Instance variables 172 may maintain the state of theinstance within the context of a business process. For example, aninstance variable may maintain the activity where an instance is at agiven moment in time during the lifetime of the instance in a businessprocess. Argument variables 174 record values that may be passed fromone business process to another business process. Methods forimplementing and using persistent variables are described in more detailin connection with FIGS. 12 and 13.

System 100 provides advantages in automating business processes 210.Business processes 210 may include activities 212 with tasks associatedwith compensation tasks. Compensation tasks are executed when anassociated task of activity 212 fails to execute, thus allowing for aconsistent state. Compensation tasks are described in more detail inconnection with FIGS. 3, 4, and 5. Additionally, activities 212 may alsobe associated with abstract roles that are used to specify users 124representing people who are responsible for performing the activity 212,thus allowing an organization to readily automate business processes210. Organizational roles are described in more detail in connectionwith FIGS. 7, 8, and 9.

Moreover, system 100 separates the processes of publishing and deployingbusiness processes 210. Business process 210 is published by matchingabstract roles with organizational roles to specify users 124representing people responsible for performing the activities of thebusiness process 210. After publishing, business process 210 may betested in a testing environment. The tested business process 210 is thendeployed to make business process 210 available to users 124 of aproduction environment. By separating the publication and deploymentprocesses, business process 210 may be published and tested, withoutdeploying business process 210 to users 124 of the productionenvironment, thus reducing risk of problems in the productionenvironment. Publication and deployment of business processes 210 aredescribed in more detail in connection with FIGS. 10 and 11.

Furthermore, system 100 provides persistent variables, which allow avalue related to an instance to be carried from one activity to anotheractivity within the same business process or between different businessprocesses. Persistent variables are described in more detail inconnection with FIGS. 12 and 13.

Compensation Tasks

FIG. 3 illustrates one embodiment of a task table 300 that records tasks310 and compensation tasks 312. Activity 212 includes a sequence oftasks 310 that are performed in order to complete activity 212. Activity212 may describe, for example, notifying a client of an incomplete salesorder. Tasks 310 may be written in any suitable computer language andmay invoke components implemented in a different computer programminglanguage such as C, C++, Fortran, Cobol, or Basic.

A task 310 may be associated with a compensation task 312 that isspecified to be executed in task 310. Compensation task 312 is onlyexecuted if its associated task fails. For example, Task 1, which mayrepresent “send email message to the client and to the financialdepartment” is associated with compensation Task 3, which may represent“send a disregarding email message to the client if the email messagecould not be sent to the financial department”. Task 3 is performed ifTask 1 fails. A task 310 is not required to have a compensation task312. For example, Task 2, which may be “send a fax to the client,” hasno associated compensation task 312. Recording tasks 310 and associatedcompensation tasks 312 in task table 300 provides for efficient andorganized storage of tasks 310 and compensation tasks 312.

FIG. 4 illustrates one embodiment of an activity properties screen 320or task definition screen, that may be used to define tasks 310 andcompensation tasks 312 of activity 212. Activity properties screen 320includes an activity tasks section 322 and a set of available taskssection 324.

Activity tasks section 322 includes windows 326 and 330 and boxes 328and 332 that may be used to define tasks 310 and compensation tasks 312of activity 212. To define a task 310, the name of task 310 may beinserted in task name window 326, and a required box 328 may be selectedin order to indicate that task 310 is mandatory to complete an instanceof activity 212. A mandatory task may comprise a task that must becompleted in order to route an instance from one activity to anotheractivity. In one embodiment, mandatory tasks must be completed in orderto route an instance from one activity to a next activity to continueexecution of activity 212. In the illustrated example, Task 1, “send anemail message to the client and to the financial department” must becompleted in order to continue execution of activity 212.

Compensation task 312 may be defined by inserting the name ofcompensation task 312 into compensation task name window 330, and arepeatable 332 box may be selected in order to indicate that task 310may be repeated a number of times. An add button 334 a, an edit button334 b, and a remove button 334 c may be used to add, edit, or removetasks 310 from activity 212. When a task is added, the new task appearsin task name window 326.

Tasks 310 and compensation tasks 312 for activity 212 may be selectedfrom set of tasks section 324. Set of tasks section 324 includes a namewindow 334 and a description window 336 that lists the names anddescriptions, respectively, of available tasks that may be selected foractivity 212. Activity properties screen 320 allows designer 122 usingProcess Designer 132 to readily specify tasks 310 and associatedcompensation tasks 312 of activity 212, thus providing for efficientdesign of business processes 210.

FIG. 5 is a flowchart illustrating one embodiment of a method fordefining and implementing tasks 310 and compensation tasks 312 ofactivity 212. In the illustrated example, Task 1, which is “send anemail message to the client and to the financial department” isassociated with compensation Task 3, which is “send a disregarding emailmessage to the client if the email message could not be sent to thefinancial department”. Task 3 is performed if Task 1 fails, that is, ifthe email message cannot be sent to the financial department, then adisregarding email message is sent to the client.

The method begins at step 350, where process designer 132 displaysactivity properties screen 320, which may be used to generate tasks foractivity 212. Activity properties screen 320 may be displayed inresponse to a user request through process designer 132. A user may, forexample, click on activity 212 of designer screen 200 of FIG. 2 torequest activity properties screen 320.

Activity properties screen 320 may be used to specify tasks 310 andassociated compensation tasks 312 of activity 212. In the illustratedexample, Task 1 is “send an email message to the client and to thefinancial department” and Task 3 is “send disregarding email message tothe client if the email message could not be sent to the financialdepartment”. At step 352, tasks 310 and associated compensation tasks312 are defined. Tasks 310 and associated compensation tasks 312 arestored in task table 159 of organizational data repository 150 at step354.

At step 356, an instance of activity 212 is requested to initiateexecution of a task 310. If activity 212 is interactive, then therequest is received from user 124. If activity 212 is automatic, thenexecution engine 140 initiates the execution of task 310. A task 310,for example, Task 1, of activity 212 is initiated by execution engine140 at step 358, that is, an email message is sent to the client and tothe financial department.

Execution engine 140 may determine that Task 1 has failed at step 360.Execution engine 140 may, for example, receive a notification that aprogram responsible for executing Task 1, such as an email softwareprogram, cannot be located. Execution engine 140 determines compensationtask 312 associated with task 310 from task table 159. In theillustrated example, task table 159 of FIG. 3 specifies that Task 3 isthe compensation task 312 associated with Task 1.

At step 364, execution engine 140 initiates compensation task 312 tocompensate for failed task 310. In the illustrated example, Task 3 maybe initiated by sending a disregarding email message to the client.After initiating compensation task 312, the method terminates. Thus, themethod provides for efficient specification of compensation tasks 312that are executed in the event an associated task 310 fails to execute.

Parametric Roles

FIG. 6 illustrates one embodiment of an organizational roles screen 400that may be used to define organizational roles and associated valuesfor an organization. The organizational roles and associated values maybe stored in organizational data repository 150. Organizational rolesare matched with abstract roles of activity 212 when a business processmodel is published into an organization. An organizational role maygroup users 124 with the same responsibility such that users 124associated with an organizational role may perform the same operationsor functions. For example, multiple users 124 may have the ability toperform the same activity 212.

An organizational role may be parametric, that is, may take on valuesthat may be associated with categories such as subsets of the group withwhich the organizational role is associated. For example, anorganizational role associated with a sales role may take on valuesassociated with sales team categories within the sales role.

Users 124 may be associated with organizational units in order todesignate other groupings of users 124, for example, groupings bydepartment or location. Organizational units may be associated withdivisions or departments within an organization context. Informationabout the organizational units may be stored in organizational datarepository 150. For example, an organizational unit may be associatedwith a particular department such as a sales department or a particularoffice location such as a Dallas office location.

Organizational units may be used to group users 124 that may accesspublished and deployed business processes. For example, an organizationdevelops a business process for processing a sales order that deals withoperations in a sales department and no other department. The businessprocess may be published and deployed to an organizational unitassociated with the sales department such that only users 124 of thisparticular organizational unit, and no other users 124, may access thebusiness process.

A value may also be associated with a time period. For example, anorganization may have one value for telephone operators who work duringa daytime period, and another value for telephone operators who workduring a nighttime period. An instance of activity 212 that occursduring a particular time period may be assigned the value correspondingto the time period. For example, an instance that occurs during adaytime period may be assigned the value for telephone operators whowork during a daytime period. An organizational role that has nospecified value is assigned a default value.

An advantage of the parametric roles may be that only one activity maybe needed for multiple parametric values, thus avoiding the need tospecify multiple activities for multiple values. Another advantage maybe that a user set 123 associated with an instance may be determineddynamically based on business process rules.

Organizational roles screen 400 includes a role name window 410 and adescription window 412, where a name and a description, respectively, ofan organizational role may be inserted. In the illustrated example, anorganizational role, Sales, is described as an organizational role forsales teams. A browse button 414 may be selected in order to viewavailable organizational roles.

Value windows 416 may be used to define values that the organizationalrole may have if the organizational role is parametric. In theillustrated example, Team A, Team B, and Team C, are the defined valuesthat the Sales may have. Add and remove buttons 418 may be used to addand remove, respectively, values. An assign organizational role button420 may be used to display assign organizational roles screen that maybe used to assign roles to users 124, which is described in more detailin connection with FIG. 7.

FIG. 7 illustrates one embodiment of an assign organizational rolesscreen 430 that may be used to assign organizational roles and values tousers 124. The organizational roles and values may be stored inorganizational data repository 150. Organizational roles are assigned tousers 124 in order to create user sets 123 corresponding to theorganizational roles.

A user I.D. window 432, a name window 434, and an email address window435 may be used to specify user 124 by inserting the useridentification, name, and email address, respectively, of user 124. Abrowse button 436 may be used to view a list of available users 124. Anorganizational unit button 438 may be used to select an organizationalunit 162 for user 124 referenced in user I.D. window 432. Theinformation may be stored in organizational data repository 150.

An organizational roles section 440 may be used to define organizationalroles assigned to user 124. Role name windows 442 and value windows 446may be used to specify organizational roles and values for parametricorganizational roles, respectively, assigned to user 124. In theillustrated example, a Sales role having Team A value, and a Trainingrole are specified for JDOE.

Permission windows 444 are used to specify the actions a user mayperform in a specified role. Possible permissions may include: executetask, abort instance, suspend instance, and route instance. Thepermission may be assigned to a particular user 124, which may providefor different users 124 associated with the same organizational rolehaving different permissions.

Add and remove buttons 448 may be used to add or remove, respectively,organizational roles. Organizational roles screen 400 and assignorganizational roles screen 430 thus allow for efficient specificationof organizational roles, values, and user sets 123. According to oneembodiment, organizational settings module 134 may be used to define andconfigure users 124, organizational roles 160, and organizational units162.

FIG. 8 illustrates one embodiment of a match roles screen 450 that maybe used to match abstract roles with organizational roles when abusiness process is published into an organization. Match roles screen450 includes abstract role windows 452 and organizational roles windows454 that may be used to specify the abstract roles and organizationalroles to be matched. In the illustrated example, Abstract Role 1 ismatched with a Sales organizational role, and Abstract Role 2 is matchedwith a Training organizational role.

Parametric boxes 456 may be used to specify whether a role isparametric. Software based on the abstract role definition may be usedto determine whether a role is parametric. If an organizational role isparametric, value windows 458 may be used to specify a value for theorganizational role. In the illustrated example, a Team A value isspecified for Sales, and nothing is specified for Training.

FIG. 9 is a flowchart illustrating one embodiment of a method fordefining and implementing organizational roles. In the illustratedexample, assign organizational roles screen 430 is used to assign Salesand Training roles to user 124 JDOE. Match roles screen 450 is used tomatch abstract roles of business process 210 with organizational rolesdefined in organization data repository 150. After role matching hasbeen performed, user 124 JDOE may have access to activities 212 a, 212b, and 212 e because user 124 JDOE has been assigned the Sales andTraining roles. As a result, user 124 JDOE is allowed to participate inthe execution of activities 212 a, 212 b and 212 e.

The method begins at step 462, where an activity 212 is associated withan abstract role. An abstract role is created using process designer132. Once the abstract role has been created, activity 212 can belocated within the abstract role location. In this case, activity 212belongs to a specific domain delimited by the abstract role. Activity212 may be defined and abstract role may be specified using designerscreen 200 of FIG. 2. Activity 212 and the associated abstract role arestored with business process 210 in organization data repository 150.

Organizational roles are added at step 464 using organizational settingsmodule 134. Organizational roles screen 400 may be used to generate arequest to define organizational roles. Values may be specified for aparametric organizational role. At step 466, users 124 are assigned toorganizational roles. The assignment specifies the activities for whichusers 124 may participate in the execution. In the illustrated example,Sales and Training are specified for user 124 JDOE. Values may bespecified for organizational roles that are parametric. In theillustrated example, a Team A is specified for Sales, and no value isspecified for Training since Training is not parametric. At step 468,organizational settings module 134 stores the organizational notes andcorresponding users 124 in organization data repository 118.

Business process 210 may be published at steps 472 and 474 using processdesigner 132 or execution console 136. Match roles screen 450 togenerate a request to match abstract roles with organizational roles isdisplayed. A user 124 such as an administrator may use match rolesscreen 450 to generate a request matching the abstract role and theorganizational role. The request is received at step 472. The abstractrole and the organizational role are matched and stored at step 474. Inthe illustrated example, Abstract Role 1 is matched with Sales, andAbstract Role 2 is matched with Training. The matching is stored inorganization data repository 150.

At step 476, execution engine 140 receives a request from user 124 todetermine activities 212 that user 124 has access or authorization toprocess. User 124 is validated and is connected to execution engine 140.Execution Engine 140 determines the organizational role or rolesassociated with user 124 at step 477.

At step 478, execution engine 140 identifies activities that user 124 isallowed to access. If the organizational role is not parametric, user124 may access activities associated with the organizational roleassigned to user 124. If the organizational role is parametric, the user124 may access instances associated with values assigned to user 124.User 124 is granted access to the allowed activities at step 480. Aftergranting access, the method terminates.

Organizational roles screen 400, assign organizational roles screen 430,and match role screen 450 allow for easy specification and matching ofabstract roles and organizational roles. Thus, the method provides forefficient definition of users 124 responsible for performing activities212 of business process 210.

Publication and Deployment

FIG. 10 illustrates one embodiment of a publish screen 500 that may beused to publish business process 210. Process designer 132 and executionconsole 136 publish business process 210 to organization data repository150 by matching abstract roles with organizational roles, and thenstoring the matched abstract roles and organizational roles inorganization data repository 150. Metadata and the structure of thebusiness process model may also be stored in organization datarepository 150. Metadata describes a graphical representation of thebusiness process model.

After publication, business process 210 may be deployed into a testingenvironment before deploying business process 210 to users 124 of aproduction environment. Process designer 132 and execution console 136displays publish screen 500 in order to match the abstract roles withthe organizational roles.

Publish screen 500 includes a “publish to” section 510, a processinformation section 512, and a commands section 514. “Publish to”section 510 is used to specify the organization and organizational unit162 for which business process 210 is to be published. Publish tosection 510 includes an organization window 516 and an organizationalunit window 518, where names of the organization and organizational unit162, respectively, may be placed. Users 124 of organizational unit 162specified in “publish to” section 510, for example, a Salesorganizational unit, may be granted access to business process 210 afterdeployment of business process 210 to a production environment.

Process information section 512 includes a name window 520 that displaysa name of business process 210 to be published, for example, Process 1.A variation window 522 is used to show the variation of the businessprocess to be published. The variation may describe, for example, abusiness process published to a specific organizational unit 162.Variations may be used if variations of the same business process are tobe used in the same organization. For example a business process may beimplemented one way in Region 1 and may be implemented another way inRegion 2. Conceptually, the business processes do the same thing, butare implemented differently.

Version window 524 displays the version of the variation of businessprocess 210 to be published. The version number may track the number oftimes business process 210 has been published. For example, a versionnumber “1.3” may indicate that a first version of the business processhas been published three times. A new major version button 526 may beselected in order to adjust the version number to show that the businessprocess to be published is a new major version. For example, versionnumber “2.0” may be used to indicate a new major version over versionnumber “1.0”.

A file window 528 is used to specify business process model location,for example, a computer associated with designer 122. A match rolesbutton 530 may be used to display match roles screen 450 that may beused to match abstract roles with organizational roles in a mannersubstantially similar to the method described in connection with FIG. 9.A deploy process in test server box 532 may be selected in order todeploy business process 210 to a test environment automatically afterpublication.

Commands section 514 may be used to specify additional commands, forexample, a JAVA compiler program used to generate business processmetadata when publishing business process 210. A browse button 534 maybe selected to list available commands that may be inserted intocommands section 514. A status window 536 shows the status of thepublication process. Okay and cancel buttons 538 may be used to submitor cancel, respectively, a request to publish business process 210.

FIG. 11 is a flowchart illustrating one embodiment of a method forpublishing business process 210. In the illustrated example, publishscreen 500 is used to publish Process 1 destined for a Salesorganization unit 162 in order to test Process 1. Process 1 is deployedto allow users of the Sales organizational unit 162 access to Process 1.

The method begins at step 560, where process designer 132 displayspublish screen 500. Publish screen 500 is used to generate a request topublish business process 210 to organization data repository 150. In theillustrated example, Process 1 is published for a Sales organizationalunit 162. Publish screen 500 is also used to access match roles screen450 to generate a request to match abstract roles and organizationalroles. In response to the request, process designer 132 matches abstractroles and organizational roles at step 562.

At step 564, process designer 132 initiates publication generating asuitable object-based code such as Java code for the tasks of activities212 of business process 210. The code is then compiled using a suitablecompiler such as a Java compiler. The code may also be packaged andcompressed by using a suitable compression method such as zipcompression. At step 566, process designer 152 completes publication bystoring the code and the material abstract roles and organizationalnotes in organization data repository 150.

At step 568, the method determines whether business process 210 is to bedeployed to a testing environment. Designer 122 of the organization mayinspect and test published business process 210 in a test environment todetermine whether it is ready for deployment. If business process 210 isnot ready for deployment at step 568, the method terminates.

If business process 210 is ready for deployment at step 568, the methodproceeds directly to step 574. At step 574, business process 210 isdeployed to organizational unit 162 using execution engine 140 specifiedat step 560. Users of organizational unit 162 may be granted access tobusiness process 210 after deployment. After deploying business process210, the method terminates. To summarize, the method provides forpublication of business process 210 that allows for inspection andtesting of business process 210 without deployment of business process210 to a production environment.

Persistent Variables

FIG. 12 is a flowchart illustrating one embodiment of a method forimplementing an instance variable, a type of persistent variable. Aninstance variable allows for a value associated with an instance ofbusiness process 210 to be transferred from one activity 212 to anotheractivity 212 of business process 210. Business process 210 may include,for example, activities 212 for processing a sales order, and theinstance may describe the processing of a specific sales order. Theinstance is associated with an instance variable, which may describe,for example, a requested quantity of goods for that particular salesorder.

The method begins at step 610, where an instance of business process 210is initiated. A first activity 212 a of business process 210 is executedat step 612. At step 614, a value corresponding to the instance variableis received. The value may describe a quantity of goods. Executionengine 140 records the value and the instance variable in objects atstep 616. The objects may comprise, for example, a Java object. Theobjects are serialized at step 618 so that the objects can be persistedin a data repository. A serialization mechanism may be used for complexstructures. At step 620, the objects are stored in transactional datarepository 118.

At step 622, a second activity 212 b of business process 210 isexecuted. Activity 212 b may require the value for the instance variablethat was received during execution of first activity 212 a. At step 624,the objects that record the value are retrieved from transactional data170 for use by second activity 212 b. To determine the value previouslyset in activity 212 a, the value retrieved from transactional database170 may be deserialized to be read by the task in second activity. Afterretrieving the objects, the method terminates.

FIG. 13 is a flowchart illustrating one embodiment of a method forimplementing an argument variable, another type of persistent variable.An argument variable allows for a value to be transferred from onebusiness process 210 a to another business process 210 b. For example, afirst business process 210 a may describe processing sales orders, andan instance may describe processing a specific sales order. The instanceis associated with an argument variable that describes, for example, arequested quantity of goods for the particular sales order. A secondbusiness process 210 b may describe determining the inventory of a typeof goods, and may require information about quantities of goodsrequested by sales orders. An argument variable allows for informationabout requested quantities of goods to be transferred from firstbusiness process 210 a to second business process 210 b.

The method begins at step 650, where an instance of first businessprocess 210 a is initiated by execution engine 140 with a value for aprocess instance variable as described in FIG. 12. First businessprocess 210 a, includes an activity that connects first business process210 a with second business process 210 b. An instance variable of firstbusiness process 210 a is associated with an argument variable used tosend a value to second business process 210 b. At step 652, a valuecorresponding to the argument variable is received. The value maydescribe a quantity of goods. The value for the corresponding argumentvariable is recorded in objects. The objects may comprise, for example,a Java object. The objects are serialized at step 656 for recording theobjects in a data repository. At step 658, the serialized objects arestored in transaction database 170 of data repository 118.

At step 660, a process instance variable of second business process 210b is initiated with a default value. At step 662, the argument variableof first business process 210 a is mapped to the instance variable ofsecond business process 210 b and persisted in transactional database170. At step 664, the objects that record the value for process instancevariable are retrieved from transactional data 170 for use by theinstance of second business process 210 b. After the objects areretrieved, the method terminates.

Embodiments of the present invention provide advantages for automatingbusiness processes 210. Business processes 210 may include activities212 with compensation tasks 312. Compensation tasks 312 are executedwhen an associated task 310 of activity 212 fails to execute.Additionally, an activity 212 may be associated with an abstract role toefficiently specify users 124 representing people who are responsiblefor performing the activity 212.

Moreover, the processes of publishing and deploying business processes210 are separated. By separating the publication and deploymentprocesses, business process 210 may be published and tested, withoutdeployment of business process 210 to organizational unit 162.Furthermore, system 100 provides persistent variables, which allow avalue related to an instance to be carried from one activity to anotheractivity. Consequently, embodiments of the present invention provideeffective and efficient systems and methods for automating businessprocesses 210.

Distributed Process Flow

FIGS. 14 through 18 illustrate embodiments of distributed process flow.Distributed process flow provides for the definition of distributedprocesses, which may improve process design and implementation.Distributed process flow may be applied to any suitable softwareprogram.

According to one embodiment, distributed process flow is applied to abusiness designer 700. According to the illustrated example, businessdesigner 700 offers the following distributed features: asynchronousprocess creation, synchronous process creation, process-to-processnotification, external notification to processes, and processinterruption. Distributed process flow may be applied to any procedure,for example, process modularization, logical distribution ofimplementable processes, task parallelization, or notification betweenprocesses.

Asynchronous Process Creation

FIG. 14 illustrates an example of asynchronous process creation, whichmay be called non-blocking process creation. Asynchronous processcreation allows for a first business process to create an instance in asecond business process represented by an activity of the first businessprocess. According to one embodiment, instance creation is requested bya parent business process 710, and the instance is created in a childbusiness process 712.

An instance of parent business process 710 is not required to wait foran instance in child business process 712 and may continue flowingthrough parent business process 710. Both instances may run concurrentlyin business processes 710 and 712. An asynchronous instance creation mayoccur in the same business process 710, which involves calling businessprocess 710 recursively.

In the illustrated example, once an order is received and processed in aFather parent process 710, the order is sent to Post Order child process712 for further processing. Post Order child process 712 is representedby a process creation activity. Father parent process 710 is notrequired to wait until order processing in Post Order child process 712is completed.

Each business process 710 and 712 may have incoming parameters, known asincoming arguments. When an instance is created asynchronously in childbusiness process 712, parameters are passed to child business process712.

Synchronous Process Creation

FIG. 15 illustrates an example of synchronous process creation, whichmay be called blocking process creation. Synchronous process creation issimilar to asynchronous process creation, however, an instance in aparent business process 714 waits until an instance in a child businessprocess 716 is complete. Once the instance of child business process 716is complete, the instance in parent business process 714 continues toflow through parent business process 714. When an instance is createdsynchronously in child business process 714, arguments are passed tochild business process 714.

In the illustrated example, Father parent process 714 waits for aresponse from Delivery child process 716 to confirm successful deliveryof goods stated in the order.

Process-to-Process Notification and External Notification

FIG. 16 illustrates an example of process-to-process notification andexternal notification. Process-to-process notification and externalnotification allow for communication and synchronization betweenbusiness processes.

Process-to-process notification is based on process notification andnotification wait activities. The process notification activity is usedto send a notification to an instance at a notification wait activity ofa second business process. If the instance is not at the notificationwait activity, the notification is stored at the execution engine 140.The instance is notified when it reaches the notification wait activity.If the notification wait activity has not received the notification, theinstance waits until the notification arrives and is notified by theexecution engine 140, after which the instance may continue to flowthrough the business process.

Three types of relations between business processes: child-parent,parent-child, process-external event. A child-parent relation existswhen a parent business process creates an instance in a child businessprocess, and the child business process sends a notification to theparent business process, which is managed by business designer 700. Aparent-child relation exists when a parent business process creates aninstance in a child business process and the parent business processsends a notification to the child business process, which is managed bybusiness designer 700.

A process-external event relation exists when an external source sendsan external notification to an instance in a notification wait activityof a business process. The external source may comprising a programwritten in a different programming language or a process not related tothe business process by a parent-child relationship. The externalnotification uniquely identifies the instance to which it is sending thenotification. Parameters are used when creating instances in a processand are passed when a notification is sent to an instance in anotherbusiness process.

In the illustrated example business process 718, an order at Delivery720 to be delivered is sent asynchronously, after which processing atReview Order 722 may occur. Business process 718 waits until deliveryconfirmation is received.

FIG. 17 illustrates an example of process-to-process notification andexternal notification. In the illustrated example, a first businessprocess 724 notifies a second business process. First business process724 sends a notification to the second business process waiting for thedelivery confirmation.

Process Interruption

FIG. 18 illustrates an example of process interruption. Processinterruption is form of process-to-process communication. Processinterruption allows a first business process to interrupt a secondbusiness process in order to process an interruption or urgent eventover a particular instance. This notification is similar to thenotification wait activity, but in this case the instance is notrequired to be at the notification wait activity. Once the notificationis sent, the instance is taken automatically to the notification waitactivity, regardless of where the instance is in the process.

In the illustrated example, an instance in business process 730 flows toa Credit Check activity 730. Under normal conditions, the instance isprocessed without error, however, a warning may be issued to indicate anabnormality with a particular instance. Business process 730 receives anexternal notification, and the instance is automatically forwarded to aCredit Warning activity 734 and continues to flow through a ProcessWarning activity 736.

Polymorphic Sub-Process

FIG. 19 illustrates an example of polymorphic sub-processes. Apolymorphic sub-process creates instances in different child businessprocesses sharing the same interface, depending on variables embedded ina parent business process. According to one embodiment, a parent andchild business process use the same interface to communicate between thebusiness processes. An interface may be defined by the input and outputarguments of a business process and a notification wait activity. Theinstance may be routed to the correct child business process accordingto predefined variables. The variables may include, for example,organizational unit, organization, and country.

In the illustrated example, child business Process 1 740 a, Process 2740 b, and Process 3 740 c of parent business process 744 share a commoninterface 746. Common interface 746 allows a parent business process 744to create an instance in any of the child business processes 740.

Certain embodiments of the invention may provide numerous technicaladvantages. A technical advantage of one embodiment is that businessprocesses may include activities with compensation tasks. Compensationtasks are executed when a task of an activity fails to execute, thusallowing for the performance of the activity to continue uninterruptedto completion. Compensation tasks may be used for automated businessprocesses to maintain business process consistency.

Another technical advantage of one embodiment is that an activity may beassociated with an abstract role in order to specify users representingpeople responsible for performing the activity. The association mayprovide for abstract business process modeling, which may allow for thecreation of business process templates creation that may be used fordifferent organizations.

Another technical advantage of one embodiment is that the processes ofpublishing and deploying business processes are separated. By separatingthe publication and deployment processes, a business process may bepublished and tested, without deploying the business process to users.Another technical advantage of one embodiment is that persistentvariables are used. Persistent variables allow a value related to aninstance of a business process to be efficiently carried from oneactivity of the business process to another activity of the samebusiness process or of another business process.

Although an embodiment of the invention and its advantages are describedin detail, a person skilled in the art could make various alterations,additions, and omissions without departing from the spirit and scope ofthe present invention as defined by the appended claims.

1. A method for separating the publishing and deployment of a businessprocess, said method comprising: accessing a business process comprisinga plurality of activities, each activity associated with an abstractrole and including a sequence of one or more tasks; accessing aplurality of organizational roles; matching each abstract role with anorganizational role; publishing the business process to a datarepository wherein publishing the business process includes creating aplurality of object classes representing the business process having thematched organizational roles, compiling the object classes and storingthe compiled object classes in the data repository; inspecting andtesting the published business process in the data repository, withoutdeploying the business process to an execution engine; determiningwhether the business process is ready for deployment in a productionenvironment with actual users; deploying the business process to theexecution engine upon determining that the business process is ready fordeployments; executing a task of at least one activity of the businessprocess; determining by the execution engine, that the task of thebusiness process has failed; and executing a compensation task that isassociated with said task if the task has failed such that execution ofthe compensation task attains a steady and consistent state in thebusiness process. 2-3. (canceled)
 4. The method of claim 1, wherein theobject classes comprise a Java class.
 5. The method of claim 1, whereindeploying the business process further includes: specifying anorganizational unit associated with the business process, theorganizational unit associated with a set of users; deploying thebusiness process; and providing the set of users access to the businessprocess.
 6. The method of claim 1, wherein deploying the businessprocess further includes: specifying an execution engine associated withthe business process; and deploying the business process by notifyingthe execution engine of the business process.
 7. The method of claim 1,wherein deploying the business process further includes: specifying anexecution engine associated with the business process; deploying thebusiness process; transmitting an instance of the business process tothe execution engine; and executing the instance using the executionengine.
 8. (canceled)
 9. A system for publishing a business process,comprising: a first data repository operable to: store a businessprocess comprising a plurality of activities, each activity associatedwith an abstract role and including one or more tasks; and store aplurality of organizational roles; an organizational settings modulecoupled to the first data repository and operable to match each abstractrole with an organizational role; and a process designer coupled to thefirst data repository and operable to publish the business process to asecond data repository by creating a plurality of object classesrepresenting the business process having the matched organizationalroles, compiling the object classes and storing the compiled objectclasses in the data repository; a publish screen used for publishing thebusiness process; and an execution engine for executing an instance ofthe business process once the published business process has beeninspected and tested wherein the execution engine determines that a taskof the instance of the business process has failed and executes acompensation task associated with said task in order to attain a steadyand consistent state within the business process. 10-11. (canceled) 12.The system of claim 9, wherein the object classes comprise a Java class.13. The system of claim 9, wherein: the organizational settings moduleis operable to define an organizational unit associated with thebusiness process, the organizational unit associated with a set ofusers, the set of users granted access to the business process ifdeployed.
 14. The system of claim 9, wherein the process designer isoperable to: specify an execution engine associated with the businessprocess; and deploy the business process by notifying the executionengine of the business process.
 15. (canceled)
 16. The system of claim9, wherein the organizational settings module is operable to: display ascreen for generating a request; receive the request describing theabstract roles and the organizational roles; and match each abstractrole with an organizational role in response to the request. 17.Software for publishing a business process, the software embodied in amedium and when executed is operable to: retrieve a business processcomprising a plurality of activities, each activity associated with anabstract role and including one or more tasks; retrieve a plurality oforganizational roles; match each abstract role with an organizationalrole; publishing the business process to a data repository whereinpublishing the business process includes creating a plurality of objectclasses representing the business process having the matchedorganizational roles, compiling the object classes and storing thecompiled object classes in the data repository; inspect and test thepublished business process in the data repository, without deploying thebusiness process to an execution engine; determine whether the businessprocess is ready for deployment in a production environment with actualusers; deploy the business process to the execution engine upondetermining that the business process is ready for deployments executinga task of at least one activity of the business process; determining bythe execution engine that the task of the business process has failed;and executing a compensation task that is associated with said task ifthe task has failed such that execution of the compensation task attainsa steady and consistent state in the business process. 18-19. (canceled)20. The software of claim 17, wherein the object classes comprise a Javaclass.
 21. The software of claim 17, operable to: define anorganizational unit associated with the business process, theorganizational unit associated with a set of users; deploy the businessprocess; and provide the set of users access to the business process.22. The software of claim 17, operable to: define an execution engineassociated with the business process; and deploy the business process bynotifying the execution engine of the business process.
 23. The softwareof claim 17, operable to: define an execution engine associated with thebusiness process; deploy the business process; transmit an instance ofthe business process to the execution engine; and execute the instanceusing the execution engine.
 24. (canceled)
 25. A system for publishing abusiness process, the system comprising: a first data repositoryoperable to: store a business process comprising a plurality ofactivities, each activity associated with an abstract role; and store aplurality of organizational roles; an organizational settings modulecoupled to the first data repository and operable to: match eachabstract role with an organizational role; and define an organizationalunit associated with the business process, the organizational unitassociated with a set of users; a process designer coupled to the firstdata repository and operable to: generate a publish screen used topublish the business process; publish the business process to a seconddata repository such that the published business process is testedbefore deploying it to an execution engine, wherein publishing thebusiness process includes performing the following: creating a pluralityof Java classes representing the business process having the matchedorganizational roles; compiling the Java classes; and storing the Javaclasses in the second data repository; deploy the business process byperforming the following: defining an execution engine associated withthe business process; notifying the execution engine of the businessprocess; and providing the set of users access to the business process,the execution engine coupled to the process designer and operable toexecute an instance of the business process according to the Javaclasses wherein the execution engine determines that a task of theinstance of the business process has failed and executes a compensationtask associated with said task in order to attain a steady andconsistent state within the business process.
 26. The method of claim 1,wherein publishing the business process further includes: generatingbusiness process metadata and storing the business process metadata inthe repository.
 27. The method of claim 1, wherein generating a publishscreen further includes: generating a variation window used to show thevariation of the published business process per specific organizationalunit.
 28. The method of claim 1, wherein generating a publish screenfurther includes: generating a version window that tracks the number oftimes the business process has been published to the data repository.29. (canceled)